Secure network file access control system

ABSTRACT

A secure network file access appliance supports the secure access and transfer of data between the file system of a client computer system and a network data store. An agent provided on the client computer system and monitored by the secure network file access appliance ensures authentication of the client computer system with respect to file system requests issued to the network data store. The secure network file access appliance is provided in the network infrastructure with the client computer system and network data store to apply qualifying access policies to file system requests. The secure network file access appliance maintains an encryption key store and associates encryption keys with corresponding filesystem files to permit encryption and decryption of file data as transferred to and read from the network data store.

[0001] This application is a continuation of U.S. patent applicationSer. No. 10/201,406, filed Jul. 22, 2002, now U.S. Pat. No. ______.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention is generally related to networkinfrastructure devices supporting network access to remotely stored dataand, in particular, a secure network system utilizing an infrastructureappliance to provide authentication, access, compression and encryptioncontrols over remote file data stores.

[0004] 2. Description of the Related Art

[0005] The use and concomitant evolution of network information systemscontinues to grow at a substantial pace. Organizations of all sizes,though particularly larger, typically corporate environments, areproducing and redeploying information at increasing rates as part of thefundamental business processes implemented by those organizations. In atypical scenario, such as encountered in many parts of the financial,scientific, and manufacturing industries, various files detailingtransactions are routinely created and centrally stored for individualand aggregate processing. This same information is then routinelyredeployed for interactive use by captive customer servicerepresentatives, select component and service suppliers, and often forlimited end user access through typically Web-based network interfaces.File stores that measure in the range of tens to hundreds of terabytesare commonplace.

[0006] As an initial matter, the growth in the volume and need for wideaccessibility of information is reflected in increasing interest innetwork attached storage (NAS) and storage area networks (SANs). Thesetechnologies support a network-based storage architecture that enables afundamental independence between the various client, application andnetwork server systems used to access and process stored data and theexpansion, configuration, and management of large data storage systems.Other fundamental capabilities provided by network-based storagearchitectures include the ability to geographically distribute and,further, replicate the data stores, which permit remote data backup andhot fail-over of typically business and real-time transaction processingstorage systems.

[0007] While the many enabling capabilities of network-based storagearchitectures are of substantial value, issues of authentication, accesscontrol, and security over the stored data remain. Indeed, theubiquitous data accessibility inherently afforded by network-basedstorage architectures is commonly viewed as greatly exacerbating theproblems of assuring authentication, access, and security control. Thenetwork transport costs associated with delivering and accessingremotely stored data is also recognized as a significant problem.

[0008] Conventional direct attached storage (DAS) architectures,involving application and network servers with dedicated, locallyattached storage arrays, have evolved various forms of authentication,access and security controls to protect stored data. These controls runfrom basic operating system password authentication and accesspermission attributes to smart cards and physical access barriers. Thesuccessive layering of these controls can be used to progressivelyharden the underlying direct-attached storage.

[0009] While some of the conventional protection controls remaingenerally applicable to network-based storage architectures, many are,as a practical matter, ineffective. In network-based storagearchitectures, the storage accessing application servers are typicallyremotely distributed, which generally precludes any assurance thatauthorization, access, and security controls are not intentionally orinadvertently circumvented. Even fewer assurances exist for the remotelydistributed client computer systems permitted access to the networkshared with the network storage.

[0010] The vulnerabilities of conventional network-based storagearchitectures are appreciated and, as a result, have significantlylimited the rapid adoption of NAS and SAN technologies. Othertechnologies, such as virtual private networking (VPN), are useful inovercoming certain of the limitations of network-based storagearchitectures. VPNs support a robust encryption of data in transportbetween the endpoint systems within a VPN session. Thus, conventionalVPNs can be used to provide point-to-point security over datatransported between various client computer systems, applicationservers, and the network storage systems.

[0011] VPN and similar technologies, however, fail to support anymeaningful access controls or assure the continuing security of dataonce delivered to a VPN endpoint system. The underlying protocols weresimply not designed to provide or enforce storage-type access controls.VPN data, while encrypted and secure during transport, is delivered to aVPN host endpoint subject only to the access controls implemented by thehost. The data is also delivered unencrypted and thus again subject onlyto the security controls provided by the host.

[0012] Other technologies can be potentially employed to layer generalaccess and security controls onto the secure transport capabilities ofVPN and similar technologies. Various standard protocols, such as theKerberos protocol (web.mit.edu/kerberos/www/) and the LightweightDirectory Access Protocol (LDAP; www.openldap.org) can be utilized todiffering degrees to provide secure authentication, directory services,and access controls. Encrypting file systems can be utilized to securefile data as stored. Together, these technologies can provide for awell-hardened storage of data within a network-based storagearchitecture. Considering the requisite separate administration of thesetechnology layers over disparate client computer systems and applicationservers, however, makes assuring that data is properly subject torigorously enforced authentication, access and security controlspractically impossible.

[0013] Consequently, there remains a fundamental, unsolved tensionbetween ensuring only properly secure access to network-based storeddata and enabling appropriate widespread access to the data infulfillment of business process requirements.

SUMMARY OF THE INVENTION

[0014] Thus, a general purpose of the present invention is to provide anefficient network-based storage architecture utilizing a wire-speedinfrastructure appliance as a managed portal between client computersystems and network storage for the coordinated control overauthentication, access, encryption and compression of data transferredto network connected data storage.

[0015] This is achieved in the present invention by providing a securenetwork file access appliance in a network infrastructure to support thesecure access and transfer of data between the file system of a clientcomputer system and a network data store. An agent provided on theclient computer system and monitored by the secure network file accessappliance ensures authentication of the client computer system withrespect to file system requests issued to the network data store. Thesecure network file access appliance is provided in the networkinfrastructure between the client computer system and network data storeto apply qualifying access policies and selectively pass through to filesystem requests. The secure network file access appliance maintains anencryption key store and associates encryption keys with correspondingfilesystem files to encrypt and decrypt file data as transferred to andread from the network data store through the secure network file accessappliance.

[0016] An advantage of the present invention is that the secure networkfile access appliance extends comprehensive authorization, access andsecurity services from the user level down to the physical file storagelevel. Authorization protocol compliance on client systems is activelyenforced as a prerequisite for file accesses subject to the securityservices provided by the secure network file access appliance.Authorized file access requests, originating from an authorizedapplication executed within an authorized session and process, aresigned by the agent upon transmission to the secure network file accessappliance. Multiple access policies are established to differentiallyqualify received file access requests, including verifying the agentsignature to establish request authenticity and evaluating user andgroup permissions to establish file access rights. Access policiesfurther define encryption and compression services that are applied tofile data transmitted between the secure network file access applianceand network storage. Encryption of the network file data, including thetransparent storage of the encrypted file data by the network storagesystem, ensures the integrity of network file data while within themanagement scope of the secure network file access appliance.Authentication, access policy, and encryption and compression serviceexceptions are recognized as intrusion and tampering events that can be,subject to the applicable access policies, logged, issued asadministrative alerts, and used as a basis for autonomous protectionactivities, such as blocking all file access requests from a clientnetwork address.

[0017] Another advantage of the present invention is that the securenetwork file access appliance maintains a secure store of the securityencryption keys and operates autonomously to associate the applicableencryption key with encrypted file data as retrieved from a network filestore. Meta-data, stored and retrieved automatically in association withthe encrypted file data, provides a persistent encryption key identifierthat is used to identify a correct encryption key for the file data.

[0018] A further advantage of the present invention is that theauthorization, access and security services performed by the securenetwork file access appliance are performed at wire-speed, enabling thefull function of the secure network file access appliance to betransparent to the normal operation of both client systems and networkstorage systems. Data files, as encrypted by the secure network fileaccess appliance, are presented as conventional data files to thenetwork storage system. The encryption of network data files istherefore transparent to network storage systems, permitting the networkdata files to be conventionally manipulated using existing managementtools, including backup and restore utilities, yet without permittingcompromise of the security of the data file content.

[0019] Still another advantage of the present invention is that thesecure network file access appliance can implement data compression incombination with encryption to minimize the bandwidth requirements ofsecure file transfers as well as the size of the secured file data asstored. The connection throughput necessary to maintain a hot-backup andthe storage space necessary for progressive archival file backups arereduced. File data compression is accomplished with minimal degradationin the wire-speed operation of the secure network file access appliance.

[0020] Yet another advantage of the present invention is that the securenetwork file access appliance is implemented as an infrastructurecomponent, permitting easy integration in existing as well as newnetwork systems. The secure network file access appliance particularlysupports remote access to geographically distributed network storagesystems. An additional layer of access security control is providedthrough the integral implementation of firewall filtering of the networkconnections, thereby supporting centrally managed and configurableprotections against external access attacks as well as improper internalaccess attacks.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] These and other advantages and features of the present inventionwill become better understood upon consideration of the followingdetailed description of the invention when considered in connection withthe accompanying drawings, in which like reference numerals designatelike parts throughout the figures thereof, and wherein:

[0022]FIG. 1 is a top level diagram illustrating the operatingenvironment of a preferred embodiment of the present invention;

[0023]FIG. 2 is an architectural block diagram of a preferred, fixedscale appliance embodiment of the present invention;

[0024]FIG. 3 is an architectural block diagram of an alternate,highly-scalable appliance embodiment of the present invention;

[0025]FIG. 4 is a process flow diagram illustrating the deep packetanalysis processing provided in accordance with the present invention tosupport authentication and access qualification of client file orientednetwork requests directed to network storage resources;

[0026]FIG. 5 provides a process interaction diagram showing theinteroperation of client processes with an authentication agent executedby a client computer system;

[0027]FIG. 6 provides a process interaction diagram illustrating thepreferred exposure of network storage resources provided in a preferredembodiment of the present invention to provide multiple qualified viewsof the underlying file data;

[0028]FIG. 7 is a software block diagram illustrating the preferredcomponents implementing network packet protocol processing in accordancewith a preferred embodiment of the present invention;

[0029] FIGS. 8A-D illustrates the preferred decomposition of file datathrough the network packet protocol processing implemented in accordancewith a preferred embodiment of the present invention;

[0030]FIG. 9 is a software block diagram illustrating an extendednetwork packet protocol processing including firewall processing inaccordance with a preferred embodiment of the present invention;

[0031] FIGS. 10A-B illustrate the process flow of a file system readrequest and response performed in accordance with a preferred embodimentof the present invention;

[0032] FIGS. 11A-B illustrate the process flow of a file system filecreate request performed in accordance with a preferred embodiment ofthe present invention; and

[0033] FIGS. 12A-B illustrate the process flow of a file system writerequest and response performed in accordance with a preferred embodimentof the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0034] Secure network file access appliances, implemented in accordancewith the present invention, can be effectively utilized in a widevariety of network infrastructure configurations. An exemplaryinfrastructure environment 10 is shown in FIG. 1. A secure network fileaccess appliance 12 is preferably implemented in the environment 10within an intranet infrastructure 14 to operate as a communicationschannel between protected network storage resources 16, such as a SAN 18and network attached storage devices 20, and client computer systems 22,24. The secure network file access appliance 12 selectively encrypts, asdetermined by access policies implemented within the secure network fileaccess appliance 12, file data stored to the network storage resources16. In accordance with the present invention, the file data encryptionmaintains the logical file-oriented structure of the data and is thustransparent to the network storage resources 16. Furthermore, the securenetwork file access appliance 12 preferably supports operation as an IPfirewall, permitting the secure network file access appliance 12 tofunction as an exclusive infrastructure path through the intranetinfrastructure 14.

[0035] Network and other servers 26 implemented as part of theinfrastructure 14 between the secure network file access appliance 12and network storage resources 16 or as part of a NAS resource 16, 26,are unaffected by the encryption function of the secure network fileaccess appliance 12, yet are secured against unauthorized access of theencrypted content. Actively used file data encryption keys arepreferably held and managed within the secure network file accessappliance 12 alone. Network accessible trusted agent systems, providingconventional secure key archive services to the secure network fileaccess appliance 12, can be relied upon to provide long-term storage andsupport on-demand retrieval of keys. The encryption keys are not storedon or directly accessible in usable form from the network attachedstorage devices 20 or network servers 26.

[0036] Preferably, the secure network file access appliance 12 processesfile data read and write requests in aggregate at wire-speed and withminimal latency in qualifying the access privileges of each read, write,and related file access request, to selectively encrypt and decrypt filedata transferred, and further selectively compress and decompress thetransferred file data. The round-trip encryption of file data ensuresthat transfers to remote network storage resources 16 over unsecurednetworks including the Internet effectively remain secure. Round-tripcompression substantially reduces the needed file data transferbandwidth, particularly where the transfers are for repeated massarchival backups.

[0037] Implementation of comprehensive access policy controls at thesecure network file access appliance 12, essentially independent thoughadditive to those of the network storage resources 16 and file servers26, enables centralized file data access management. The accesspermissions and other controls implemented by the network storageresources 16 and file servers 26 are difficult to globally maintainthrough additions and reconfigurations of the network attached storagedevices 20 due to the typically remote and distributed nature of thenetwork storage resources 16 and file servers 26. The access policycontrols provided by the secure network file access appliance 12 aresignificantly more comprehensive, flexible, and administratively uniformthan conventional access permissions implemented by the various networkstorage resources 16.

[0038] Authentication controls are supported by the secure network fileaccess appliance 12 as a complement to the access policy controls. Forthe preferred embodiments of the present invention, authentication agentcode is installed and executed on clients 22, 24 to enable user andclient authentication, including authentication over user sessions andprocesses. For the client 22, a user 28 may represent an individual or aremotely connected computer system utilizing the client 22 as a networkfile, Web, or application server, executing conventional userapplications 30 supported by a conventional network capable operatingsystem 32.

[0039] A modified file system 34 provides for selective authenticationprocessing of file system requests directed to the network storageresources 16, including through network servers 26. For the preferredembodiments of the present invention, the file system 34 is mountedthrough a file system switch facility supported by the operating system32 against the directory nodes representing network storage resources16. Authentication logic provided in an agent program 36, executinglargely if not exclusively in kernel space, is called in response tofile system operations directed against the file system 34. Through theoperating system 32, the agent program 36 has access to user, client,process, application, and session information. Where attended userauthentication is required, the agent program 36 preferablyinteroperates through the operating system 32 to assert anauthentication dialog for the user 30. User responsive information canthen be authenticated using standard authentication controls, such asLDAP and other network available authentication servers (not shown).Alternately, or in combination, the user authentication responseinformation can be transmitted to the secure network file accessappliance 12 for security qualification.

[0040] Authentication of user applications 30 is performed autonomouslythrough the agent program 36. Preferably in response to a first filesystem operation by a user application 30, as received by the filesystem 34, or on notice from the operating system 32 of the invocationof the user application 30, the agent program 36 generates a secure hashidentification of the loaded binary image of the user application 30.This hash identifier and the application file attributes are thentransmitted to the secure network file access appliance 12 forverification. An authentication response is returned to the agentprogram 36 providing verification status. A verification failure orother exception indicated by the secure network file access appliance 12preferably results in a disallowance of the requested file systemoperation.

[0041] Unattended execution of applications by a client 22, such as onbooting of the client 22, can be supported through the applicationauthentication mechanism. Preferably, an application launcher utility isscripted to execute on boot. Through application authentication of theutility, the absence of attended user authentication derived informationis not treated as an exception by the secure network file accessappliance 12. The application launcher utility is then enabled to launcha designated application 30.

[0042] The state of user and application authentication, in combinationwith user session and associated process identifiers, is preferablymaintained by the agent program 36. In the preferred embodiments of thepresent invention, this authentication information and the digitalsignature of the agent program 36 are combined and sent encrypted to thesecure network file access appliance 12 with each file system requestpassed by the modified file system 34. A network layer 38, including anNFS/CIFS network file system layer, modified to include the user andagent authentication information with file system requests, is used tocommunicate with the secure network file access appliance 12. In thepreferred embodiment, an NFS packet header field is extended, preferablyby redefinition of an existing field, to store and transfer the user andagent authentication information. Additionally, periodic or heartbeatstatus remote procedure call (RPC) packets are sent by the agent program36 to the secure network file access appliance 12 reflecting the currentstate of the user and agent authentication information. Client changesrelevant to authentication, including specifically terminations ofprocesses and user sessions, are thereby rapidly noticed to the securenetwork file access appliance 12.

[0043] The transport of file data between the secure network file accessappliance 12 is generally secure where a client, such as client 22, ispart of the local infrastructure 14. Where the transport extends toremote clients, such as client 24, over an unsecure network, such as theInternet 40, conventional transport security protocols can betransparently employed. As shown, a virtual private network 42, can beutilized without interference with the authentication of users 30 inaccordance with the present invention. Alternatively, or in addition, asecure network file access appliance 12′ can be deployed locally withrespect to the remote client 24, thereby securing the transport of filedata effectively between the remote client 24 and network storageresources 16.

[0044] A preferred, fixed scale, hardware platform 50 for the presentinvention is shown in FIG. 2. The platform 50 is preferably implementedon a motherboard supporting the Intel® E7500 chipset 52, dual 2.2 GHzIntel® Xeon™ processors 54 (Intel Corporation, Santa Clara, Calif.;www.intel.com), and a 1-Gbyte 200-MHz Double Data Rate (DDR) main memoryarray 56. The chipset 52 supports six PCI-X buses 58, individuallycapable of over 8-Gbps throughput and an aggregate throughput of atleast 24-Gbps. A basic configuration of two 1-Gbps network interfacecontrollers, supporting ingress and egress network connections, and one10/100 Mbps network interface controller, supporting a managementnetwork connection, are connected to the PCI-X bus 58. A baseconfiguration of three HiFn™ 7851 security processors 62 (Hifn, Inc.,Los Gatos, Calif.; www.hifn.com) provides hardware acceleratedencryption and compression support for the generic data processing andcontrol function of the processors 54. The security processors supportsymmetric programmable length block encryption algorithms, including3-DES, at throughputs in excess of 400-Mbps per chip and programmablelength block compression algorithms, including LZS, at throughputs inexcess of 80 MBps.

[0045] Other peripherals 70, including a BIOS program and boot hard diskdrive, are supported though the chipset 52 to enable basic operation ofthe platform 50. Preferably, the platform 50 boots and runs a Linux™based operating system, based on a commercial distribution of Red Hat™Linux (Red Hat, Inc., Raleigh, N.C.; www.redhat.com). The software-basedauthentication and access functions of the secure network file accessappliance 12 preferably load and execute in the Linux kernel space.Administrative and support utilities are preferably implemented asuser-mode applications and daemons.

[0046] An alternate, high-throughput, scalable hardware platform 80 forthe secure network file access appliance 12 is shown in FIG. 3. Thisscalable architecture is generally consistent with the architecturedisclosed in Network Media Encryption Architecture and Methods forSecure Storage, Ser. No. 10/016,897, filed Dec. 3, 2001 by Pham et al.,which is hereby incorporated by reference. In brief, multipleblade-based access processors 82 _(1-N) each preferably implements acentral processor executing an instance of an embedded Linux operatingsystem. One or more encryption and compression security processors areprovided on each blade as hardware acceleration engines. In place of thedirect network interface connections 62, packet connections through ahigh-speed switch fabric 84 provide data paths to an ingress processor86 and an egress processor 88 that serve as packet routers to 10 Gbps orhigher throughput network infrastructure connections 90, 92.

[0047] A control processor blade 94 manages and monitors the otherblades 82 _(1-N), 88, 90. The control processor blade 94 supports thebooting of the embedded operating system instances on the blades 82_(1-N), 88, 90 and coordinates the sharing of common encryption andcompression configuration and control information between the accessprocessor blades 82 _(1-N). A separate management network interfacecontroller 96 is provided to enable independent access to the controlprocessor 94 from the management network 98.

[0048] The logical control and protocol processing functions implementedin the control programs executed on a platform 50 for a preferredembodiment of the present invention are shown in FIG. 4. Inbound filerequests are received as network data packets containing the variousnetwork file system messages implemented by a network distributed filesystem, such as the network file system (NFS) and common internet filesystem (CIFS). These network data packets are processed to expose thecontrol information 114 contained in the protocol layers of eachreceived data packet and the packet payload data 116 for examination andprocessing.

[0049] Additionally, application and status information is gathered byan agent monitoring process 118 listening on a dedicated network portfrom network connected clients 22, 24. Client status information,obtained from heartbeat network packets, is relayed to an authenticationand access control process 120. Continuity of a client heartbeat is usedto maintain a client authorization session. User authentication sessioninformation, minimally reflecting that a user authentication sequencemediated by the agent program 36 has completed successfully, can also beprovided to the authentication and access control process 120 within theheartbeat data packets. Transmission of user authentication sessioninformation at checkpoint intervals serves to protect against conversionof any client process for the execution of unauthorized applications.Where the authentication and access control process 120 operatesdirectly as an authentication server, user and client identifiers anduser password acquired by the agent program 36 are relayed through theagent monitor process 118. Authorization responses are generated andreturned by the authentication and access control process 120 based onthe user and client authentication policy information maintained by theauthentication and access control process 120.

[0050] In reference to FIG. 5, authentication enforcement is enabled byrequiring a call to the agent program 36 in connection with theinitialization of a new user process 132. User authentication isperformed directly by a user mode component of the agent program 36through a conventional authentication service, such as LDAP, against auser login and password. Alternately, user authentication can be directthrough a pluggable authentication module generally consistent withDCE/OSF-RFC 86.0 (Unified Login with Pluggable Authentication Modules(PAM); www.opengroup.org/tech/rfc/rfc86.0.html). In either case, theagent program 36, on authentication of the user, establishes anauthenticated user session defined by the login process identifier(LPID), a user identifier (UID), and a group identifier (GID), asestablished by and obtained from the operating system 32.

[0051] The authentication modified filesystem 34 receives file requests134 issued by a user process 132. A kernel mode portion of the agentprogram 36, operating in conjunction with the authentication modifiedfilesystem 34, determines the source process identifier for each filerequest 134 by accessing operating system 32 structures. Theauthenticated user session information maintained by the agent program36, located by the determined process identifier, is then provided tothe modified network layer 38 for inclusion in the network file systemrequests 134 as processed through the network layer 38.

[0052] Client processes 136 spawned from an authenticated process 132remain part of the parent authenticated user session. The chain ofparent process identifiers is traced by the agent program 36 toassociate file requests 138 from child processes 136 with correspondingauthenticated user sessions. Preferably, to support access management atthe level of individual processes, both the authenticated user loginparent process identifier (LPID) and the current process identifier(PID) are provided to the modified network layer for inclusion in thesession and process corresponding file requests forwarded to the securenetwork file access appliance 12.

[0053] In a preferred embodiment of the present invention, theauthenticated user session information, including a session identifiergenerated by the agent program 36, is encrypted using a session keyobtained through a secure key exchange with the agent monitoring process118. The resulting extended NFS requests thus securely transport thesession control information, including at least a session identifier,request source IP, user identifier, group identifier, and processidentifiers to the secure network file access appliance 12.

[0054] Preferably, the agent program 36 supports authentication of userapplications 30 as loaded for execution in the authenticated usersession processes 132, 136. Digitally signed applications loaded forexecution can be verified conventionally by the agent program 36 againstdigital certificates obtained from a trusted PKI, LDAP or otherauthentication server. Application authentication information, such asthe identity of the authentication server and certificate, can bepotentially included by the modified network layer 38 with the sessioninformation provided with corresponding file requests to supportauditing of independently verified applications.

[0055] Autonomous application authentication by the agent program 36 isalso supported through the secure network file access appliance 12. Onthe loading of an application for execution in a process 132, 136, theagent program 36 is called and executes, through the operating system32, to locate 142 the application binary image and retrieve theapplication file attributes, including the application filename, path,permissions, and file size. A secure hash signature is generated for theapplication binary. In a preferred embodiment of the present invention,a 20-byte hash signature is generated using the SHA-1 algorithm. Anapplication authentication request, containing the hash signature, fileattributes and a secure application token, is then passed to the securenetwork file access appliance 12 in an RPC directed to the agentmonitoring process 118. The secure application token preferably includesa public key, of a public/private key pair stored by the secure networkfile access appliance 12 or trusted third-party authentication server,an application name, and a structure containing a secure hash signatureof the application binary image and the application file attributesencrypted with the public key. The token is prior administrativelygenerated through the secure network file access appliance 12 or othertrusted application authenticator against an administratively determinedauthentic application. The tokens for authenticated applications arestored on or otherwise made accessible to the clients 22, 24. Theapplication file name located for the loaded binary image is used tofurther locate a corresponding token by the agent program 36.

[0056] On presentation of an application authentication request, thesecure network file access appliance 12 compares the public key providedwithin the token against known valid public keys prior administrativelyregistered with the secure network file access appliance 12. Thedecrypted token hash signature and file attributes are verified againstthe hash signature and file attributes separately provided in therequest by the agent program 36 and a return RPC communicates theverification status to the agent program 36. Where the loadedapplication fails authentication, the corresponding application process132, 136 can be terminated. Alternately, subsequently received networkfile system requests 134, 138 from an unauthorized application can beignored or refused by the modified file system 34. Thus, within anotherwise authenticated user session, the application authenticationprovisions of the present invention can enforce explicit and functionallimitations on user process execution to a well defined set ofauthenticated applications.

[0057] Referring again to FIG. 4, packet control information 114 andapplication information 122, exposed by packet processing 112 and asreceived from the agent monitoring process 118, is provided to theauthentication and access control process 120 for each network file datapacket received by the secure network file access appliance 12.Preferably, the authentication and access control process 120 includes apolicy store representing the administratively determined, functionallysupported operations of the secure network file access appliance 12. Thepolices are preferably stored in a high-performance hash tablepermitting a policy lookup against the information 114, 122 as presentedto the authentication and access control process 120. Audit logs of thefile requests, as well as error logs and logs of refused operations areproduced by the authentication and access control process 120.

[0058] Policy sets applicable to a received network file packet can beprogressively discriminated based on any of the data provided in thepacket control information 114. In particular, IP layer data providessource and destination IPs, permitting specific access constrains to bedefined against defined clients, individually or by subnets. Thestandard NFS/CIFS layer data provides the requesting user UID and GID,as well as the fully qualified file or directory reference, includinggenerally a mount point, file system path, and applicable file name. Theapplication information 122 layer identifies the user session andprovides the execution and parent process identifiers. Where utilized,the application information 122 layer also provides the application nameand signature. Successful discrimination of the policy sets against theprovided information 114, 122 enables and qualifies the processing ofnetwork file packets transported relative to the network storageresources 16.

[0059] Preferably, the handling of the various possible types of policyset discrimination failures is defined by the policy sets.Discrimination failures will typically include user authorizationfailures and unauthorized application execution attempts, unauthorizedsource IP addresses, and improper file references due to unavailabilityof the referenced file or lack of adequate user, group or filepermissions. Depending on the nature of the failure, the discriminationfailure handling defined by the policy sets will direct the productionof detailed audit and error log entries and immediate issuance ofadministrative alarms, including potentially the automated generation ofemail and voice messages. The policy set discrimination failure handlingpreferably further defines the type and content of any NFS/CIFS networkfile error data packets generated by of the NFS/CIFS state machine 124and returned to a client 22, 24.

[0060] In accordance with the present invention, the progressivediscrimination of the policy sets also determines the active applicationof encryption and compression to the packet payload data 116. Forinbound network file data packets from clients 22, 24, any combinationof data provided in the control information 114, 122 can be utilized asa signature identifying whether the packet payload data is to beencrypted against a particular encryption key and compressed using aparticular compression algorithm. A preferred basic policy setessentially defines the combinations of source IPs, user identifiers,and group identifiers permitted access through the mount point and,further, a default encryption key to be used, particularly for filecreation. Multiple policy sets can be applicable to the some mountpoint, differing in the specification of source IPs, user identifiers,and group identifiers or by specification of additional controlinformation, such as the path specification and file-type extension forthe network file identified in the request. The policy sets areadministratively managed to ensure that unique combinations of theprovided control information resolve to distinct policy sets. Where pathspecification information is utilized to establish the scope ofotherwise matching policy sets, a best match of the path specification,file name, and file extension is preferably used to discriminate thedefault applicability of data encryption and compression.

[0061] Network file packets returned from network storage resources 16are similarly processed 112 to expose the packet control information 114and permit a combination of data to be considered in determining whetheraccompanying pocket payload data requires decompression and decryption.While, in accordance with the present invention, encrypted network datapackets returned from the network storage resources 16 can be presumedsecure, examination of the control information 114 throughauthentication and access processing 120 enables an appropriateauthentication of the source and sequence of the returned network filepackets.

[0062] Preferably, packet payload data presented to the secure networkfile access appliance 12 and determined to be encrypted or compressed isprocessed into a sequence of logical access blocks (LABs) through anencryption and compression process 126. As part of the encryption andcompression process 126, each logical access block is, in accordancewith one preferred embodiment of the present invention, marked with atleast an indirect identifier of the applicable encryption key andcompression algorithm. Thus, while the decompression and decryptionstatus of outbound network data packets may be suggested by a sourcedirectory specification, the applicable encryption key and compressionalgorithm is determined based on the encryption and compressionidentifiers associated with the logical access blocks. Decryption anddecompression of the logical access blocks are, therefore, notessentially dependent on the directory specification or otherindependently alterable aspects of the network file.

[0063] Discrimination of applicable policy sets is, in accordance withthe preferred embodiments of the present invention, expanded through thesupport by the secure network file access appliance 12 of multiple,inbound virtual mount points for the various network storage resources16. As shown in FIG. 6, multiple virtualized mount points /dev/hd_a,/dev/hd_b, /dev/hd_c, and /dev/td_d may be defined administratively inthe configuration of the secure network file access appliance 12. Thesevirtual mount points are independently associated through a definedmapping with the same, as by alias, or separate real mount pointssupported by various network storage resources 156, 158. Client 152, 154file requests to mount any of the virtual mount point representednetwork file systems can be qualified and constrained by policy setsthat, at a minimum, serve to validate the existence of the virtual mountpoint and, optionally, further discriminate for a permitted mountrequest source IP.

[0064] In accordance with the present invention, the virtual mountpoints further expand the ability to discriminate applicable accesspolicy sets for the client 152, 154 NFS/CIFS network file transactions.Control information 114 provided with each network file packet directedto the secure network file access appliance 12 identifies a target mountpoint. In accordance with the preferred embodiments of the presentinvention, the authentication and access control process 120 logicallyselects an applicable policy set based on the identified virtual mountpoint. The further constraints represented by the selected policy setare concurrently used to determine how the network file data packet isto be processed. For example, otherwise authorized clients 152, 154accessing the network resource 156 through the /dev/hd_a virtual mountpoint may be constrained to read-only NFS/CIFS transactions. Theseparate policy set associated with the /dev/hd_b virtual mount pointmay support read-write access by only a well defined set of UIDs,further constrained to NFS/CIFS requests originating from a definedsubnetwork.

[0065] As another example, read-write access of the network storageresources 156 by the client 154, administratively limited to providingbackup services, may be broadly supported through the virtual mountpoint /dev/hd_c. The policy set associated with the mount point/dev/hd_c preferably enables read-write access to the network storageresources 156 while disallowing decryption of previously encryptedfiles. The policy set for the virtual mount point /dev/td_d preferablyprovides for the encryption and compression of previously unencryptedfiles upon writing to the archival network storage resources 158 and fordecryption and decompression on reading. Consequently, a user withlimited backup access rights can fully administer the backup and restoreof files without breach of the secure storage of previously encryptedfiles. Thus, distinguishing policy sets based on virtualized mountpoints provides an extensive degree of flexibility in managing theaccess rights of a community of clients 152, 154.

[0066] Network file packets permitted or refused by operation of theauthentication and access control process 120 are signaled to anNFS/CIFS state machine 124, as shown in FIG. 4. The sequences of networkfile packets representing select file data transactions, includingspecifically NFS/CIFS transactions, are tracked by the NFS/CIFS statemachine 124, in accordance with the present invention, to support theselective encryption and compression of NFS/CIFS network packettransferred file data and manage the attendant changes in the size andstructure of network files as stored by the network storage resources16. Mount and unmount request RPCs are essentially atomic operationsbetween the clients 152, 154 and the secure network file accessappliance 12. On receipt of a mount request, access is optionallydetermined by the authentication and access control process 120 based onthe applicable policy set and a determination that the underlyingnetwork storage resource 16 identified with the corresponding real mountpoint is available. An RPC response acknowledging the success or failureof the mount or unmount request is then returned.

[0067] The NFS/CIFS state machine 124 tracks the state of each NFS/CIFStransaction processed through the secure network file access appliance12. The principle NFS/CIFS transactions tracked include Read, Write, andCreate. All other NFS/CIFS defined transactions (generically Requests)are also tracked by the NFS/CIFS state machine 124. The Readtransaction, following from an inbound read request for file datadefined by an offset and range, involves building a corresponding readrequest with the read offset adjusted back to an encryption andcompression block boundary and the range adjusted to allow for theencryption and compression of the file data through to the end of ablock boundary. The next states include issuing the read request to thenetwork storage resources 16, receiving a responsive series of networkread file data packets, and processing, as needed, to decrypt anddecompress the received packet payload data. The final read transactionstates include extracting the read file data for the originallyrequested offset and range and building and returning one or morenetwork file data packets with the read file data.

[0068] An NFS/CIFS Write transaction requires a read/modify/writeoperation where existing stored file data is encrypted or compressed. Awrite transaction includes receiving a write request, building a lockrequest with a write lock offset adjusted back to an encryption andcompression block boundary and the range adjusted to allow for theencryption and compression of the file data through to the end of ablock boundary. The next transaction states include issuing a readrequest for any initial and final partial file data page including theadjusted write offset and range terminus, decrypting, decompressing andmodifying the read data page to include the corresponding parts of thefile write data as received from the client, encrypting and, asappropriate, compressing the file write data, and building and issuingcorresponding write requests to the network storage resources 156. Thefinal write states include building and sending an unlock request to thenetwork storage resources 156 and building and sending a write requestreply to the client.

[0069] NFS/CIFS Requests, such as get and set attributes, get accesspermissions, and make directory, are generally atomic transactionsmanaged by the secure network file access appliance 12 to supportinfrastructure compatibility with the network storage resources 156.Request transactions involve receiving a client request and building andsending a corresponding request to the network storage resources 156.Upon receipt of a request response from the network storage resources156, adjustments are made for the reported file size and otherattributes of the network file as stored on the network storageresources 156 depending on the particular request involved in thetransaction. A corresponding request response is then constructed andsent to the client.

[0070] An NFS/CIFS Create transaction involves receiving a file createrequest, constructing a file management header for the new file, andbuilding and sending a corresponding request to the network storageresources 156. Upon receipt of a request response from the networkstorage resources 156, a corresponding request response is againconstructed and sent to the client.

[0071]FIG. 7 provides a block diagram and flow representation of thesoftware architecture 170 utilized in a preferred embodiment of thepresent invention. Inbound network communications are processed througha first network interface 172. Network file data packets received fromclients 22, 24 are processed 174 to expose and deliver the networkcontrol information 114 for authentication processing 176. Applicationcontrol information 122 collected from corresponding agent applications28 are provided through an agent interface 178 in support of theauthentication processing 176.

[0072] Based on interactions with a policy parser 180, selected elementsof the network and application control information 114, 122 are comparedwith authentication parameters maintained in a policy data store 182.The policy parser 180 preferably implements decision tree logic todetermine the level of authentication required for processing thenetwork file request represented by the network file data packetreceived and whether that level of authentication has been met.

[0073] The network and application control information 114, 122 is alsoprocessed 184 to determine whether the authorized user is permittedaccess to the corresponding network storage resources 16. The policyprocessor 180 and policy data store 182 operate to determine whether theaccess attributes provided with the network file request are appropriateto enable access to the specific network storage resources 16 identifiedby the network file request.

[0074] While logically separate operations, the authentication andaccess processing 176, 184 are preferably performed concurrently. In apreferred embodiment of the present invention, a basic decision treelogic sequence considers the logical combination of network fileoperation requested, virtual mount point, target directory and filespecification, client IP, user UID and GID, and the client session andprocess identifiers. Also considered is application authentication dataprovided with the network file request and as prior provided by theagent program 36 and the continuity state of the client session asperiodically reported by the agent interface 178. Additional state dataaccumulated in relation to the nature, timing, and frequency of networkfile access requests is considered. This state data is accumulated bythe secure network file access appliance 12 to support static timescheduling and quota controls over network file access requests as wellas dynamic traffic shaping of the network file access operationsprocessed through the secure network file access appliance 12. Theaccumulated state data also permits dynamic detection of patterns infile access requests that threshold qualify as intrusion attempts orother circumstances warranting issuance of an administrative alarm. Thedecision tree evaluation considers prior sequences of file accessrequests and thereby qualifies the permitted support of a currentnetwork file access request.

[0075] Policy data is administratively established to define the set ofvirtual mount points and the mapping of virtual mount points to realmount points. The policy data can also variously define permitted clientsource IP ranges, whether application authentication is to be enforcedas a prerequisite for client execution or operative response by thesecure network file access appliance 12, a limited, permitted set ofauthenticated digital signatures of execution or response enabledapplications, whether user session authentication extends to spawnedprocesses or processes with a different UID or GID, and other data thatcan be used to match or otherwise discriminate, in operation of thepolicy parser 180, against the control information 114, 122. Thisadministratively established policy data is logically accessed from thepolicy store 182 by the policy parser 180 in the evaluation of thenetwork and application control information 114, 122. For the preferredembodiments of the present invention, the decision tree logic and policydata are stored in a hash table permitting rapid evaluation of thenetwork and application control information 114, 122.

[0076] The network and application control information 114, 122, as wellas the determined results of the authorization and access processing176, 184 are control inputs to an NFS/CIFS state machine process 186.Non-file data messages, including various NFS/CIFS request and replymessages involved in the read, write, and create NFS/CIFS transactionsequences, are prepared and forwarded 188, 190 directly from the statemachine process 186 to the inbound network interface 172 and an outboundnetwork interface 192. Policy data needed to support the generation ofnetwork file request and reply data packets, such as virtual to realmount point mapping data, is accessed from the policy data store 182 asneeded.

[0077] Where ordinary network file data is included in a network filedata packet inbound from a client 22, 24, the packet payload data 116 isprocessed 194 into a sequence of logical access blocks (LABs), providedthe network file data packet is qualified through access processing 184for encryption or compression. The packet payload data 116 ofunqualified network file data packets are processed 194 unchanged intonetwork data packets and provided to the network interface 192 fortransmission to the network storage resources 16.

[0078] As represented in FIG. 8A, the packet payload data of networkfile data packets corresponds to read and written portions of a file 220recognized by a file system 36. Individual packet payload data 222,generally as shown in FIG. 8B, is preferably processed 194 into asequence of logical access blocks 224 _(1-N), as shown in FIG. 8c witheach logical access block containing a corresponding portion of thepacket payload data 222. In an initial embodiment of the presentinvention, the file management header 226 is virtualized for all filesassociated with a real mount point and locally stored by the platform 50effectively as part of the policy data held by the policy store 182. Theapplicable file management header is retrieved as part of the policy setapplicable to the requested virtual mount point. The preferredembodiments of the present invention provide for the creation of a filemanagement header 226 in connection with each Create file NFS/CIFStransaction. In one embodiment, the file management header 226 iscreated and written to the network storage resources 16 effectively asthe first file data block as part of the creation of the file 220 on thenetwork storage resources 16. One or more logical access blocks 224 canthereafter be appended to the file as created on the network storageresources 16 and, subsequently, read and written in random order.Alternately, to optimize the storage and retrieval of data with respectto the network storage resources 16, individual or subsets of logicalaccess blocks 224 and the file management header 226 can be written toseparate I/O pages within the same or different file spaces and storagedevices. In either case, in accordance with the present invention,qualified file data reads and writes directed to the network storageresources 16 are performed as discrete, logical access block-alignedtransfers encompassing the offset and range of a client network filedata request.

[0079] The file management header 226 and logical access blocks 224 arerepackaged in network file data packets as otherwise ordinary blocks offile data for transport to the network storage resources 16. Theencryption and/or compression of network file data by secure networkfile access appliance 12 is thus entirely transparent to the reading andwriting of relative to the network storage resources 16 by operation ofthe present invention.

[0080] A preferred structure of the file management header 226 is shownin FIG. 8D and further detailed in Table I below. Preferably, the filemanagement header 226 includes a unique file GUID 228, securityparameter index (SPI) 230, and a security signature 232. The file GUID228 is preferably a SHA-1-based secure hash of data related to the file,such as the client IP, user UID, and file creation time to provide a160-bit unique random identifier for the file. The security parameterindex 230 is preferably a composite of security information including anencryption key identifier (Key) 234, a security options array (Idx) 236,and file related information (Info) 238.

[0081] The encryption key identifier 234 is preferably an encryptedrepresentation of the encryption key name utilized to encrypt the filedata contained in the logical access blocks of the file 220. Encryptionkey name/key value pairs are utilized by the secure network file accessappliance 12 are administratively defined and stored in the policy datastore 182. When, as a product of access processing 184, an encryptionkey is associated with a new file, the corresponding encryption key nameis securely digested, again preferably using the SHA-1 algorithm, andstored in the key identifier field 234 of the file management header226.

[0082] The security parameter index 230 may optionally also include alinked list storing, in encrypted form, the encryption key value for thefile 220. Each entry in the linked list includes a public key, encryptedkey value tuple. The public key corresponds to a trusted encryption keyagent server and the encrypted key value is encrypted with the publickey of the agent. On retrieval of the network file data by a differentsecure network file access appliance 12′, the public key identifiedagent server can be used to recover the encrypted key value. Providingsupport for multiple independent agent servers ensures that theencrypted key value can always be recovered. TABLE I Management HeaderStructure Struct MGT_BLOCK { U32 File_GUID[5]; // 160-bit unique randomGUID for File U32 Mgt_Hdr_Ver; // 32-bit version identifier for thisstructure U32 Size_Mgt_Blk; // Size of the management block structureU32 Options[]; // Option include // --IntegrityMode: to compare digitalsignatures // --OutOfBand: out-of-band meta-data used // --CypherName:encryption algorithm ID // --ComprName: compression algorithm ID //--UserEncryption: Key_GUID is a user key // --GroupEncryption: Key_GUIDis a group key // --HaveKeys: has list of agent encrypted keys U32Key_GUID[5]; // 160-bit GUID for Key, generated by // SHA-1 (KeyName)U32 Creator_GUID[5]; // 160-bit GUID identifying the file creator BYTEInit_Vector[8]; // Initial seed value for LAB encryption; // encryptionseeds are a function of // Init_Vector + LAB Offset U32 Padding[]; U32CRC; // To verify management header block integrity BYTE Signature[128];// Signature, signed with PrivKey for // PublicKey_Verify Pre-computed.// Signs only static part of the structure to // avoid overhead on eachfile under the same // volume/policy. CRC is signed as the last part //so that changing to any part of the whole // block is detected.*Key_Table // Linked list of Public Key, agent encrypted // LABSymmetric Key tuples }

[0083] The security options array 236 provides an indexed list of thesecurity functions applied to the logical access blocks 224 associatedwith file management header 226. These options preferably includeidentifiers of the whether encryption is used and the applicableencryption algorithm, whether compression is used and the applicablecompression algorithm, whether the encryption key name lookup should beuser or group based, whether an agent encrypted key list is present, andwhether tamper detection through digital signature checking is to beenforced. The file related information 238 fields provide storage forvarious other information, such as a GUID corresponding to the filecreator.

[0084] Finally, the security signature 232 provides storage for a cyclicredundancy check (CRC) value and digital signature. The CRC value ispreferably computed over the binary value of the preceding portions ofthe file management header 226 to permit block integrity checking. Thedigital signature is computed for the preceding portions of the filemanagement header 226 including the CRC field to enable detection oftampering with any portion of the file management header 226.

[0085] A preferred in-band structure of logical access blocks 224 isalso shown in FIG. 8D. The primary fields of a logical access block 224include a LAB data field 240, a LAB signature field 242, and an optionalLAB compression header 244. The LAB data field 240 contains an encryptedand/or compressed portion of the packet payload data 222. The size ofthe LAB data field 240 is nominally set as a multiple of a natural orconvenient block size recognized by the file system 36 and furtherchosen for block encryption algorithm efficiency.

[0086] In accordance with the present invention, segmentation of thepacket payload data 222 into the logical access blocks 224 enablesreasonably sized blocks of file data to be encrypted and compressed asatomic units. Smaller segments sizes are preferred for obtainingrelatively efficient random read/write operations directed to the file220 as stored by random access devices within the network storageresources 16. Larger segment sizes are preferred for lower processingoverhead, greater encryption and compression efficiency, and where thetarget device within the network strange resources 16 is a streamingaccess device, such as a conventional tape drive. Preferably, the packetpayload data 222 segment size has a block modulo of eight bytes with aminimum size of 512 bytes and a nominally preferred size of 1024 bytesfor random access devices. For streaming access devices, larger blocksizes on the order of 8096 bytes may be preferred.

[0087] Where the last segment of the packet payload data 222 is lessthan the nominally preferred segment size, a smaller block size is used.This smaller block size is chosen to be the largest modulo eight byteblock size that is the same or smaller than the size of the lastsegment. All but at most seven bytes of the last segment are then blockencrypted. Any remaining segment bytes are then XORed with a mask valuegenerated by the encryption of an eight-byte length, zero-value stringand then appended to the block encrypted portion of the last segment.

[0088] The LAB compression header 242, preferably included only wherethe packet payload segment held by the logical access block 224 iscompressed, includes fields specifying the offset and range of the filedata contained within the LAB data field 240. Dependent on theunderlying data values and the stream compression algorithm applied, thesegment length or range of the packet payload data 222 stored in the LABdata field 240 is variable. The segment length is manipulated to obtaincompressed data that closely approaches the preferred LAB data fieldsize. Padding is provided to reach a modulo eight-byte encryption blockcompatible size. At a minimum, the range value identifies the actualcompressed data carried in a completed logical access block 224.

[0089] The LAB signature 244 is preferably computed as a secure digestof the LAB data field 240 and, where present, the LAB compression header242. In the preferred embodiments of the present invention, an SHA-1algorithm is used to create the LAB signature 244. The security of eachlogical access block 244, when retrieved to the secure network fileaccess appliance 12, can be assured against tampering by recomputing thesecure digest of the LAB data field 240, including any LAB compressionheader 242, and comparing against the LAB signature 244. For a preferredvariant of the present invention, network file data is stored as logicalaccess blocks 224 containing only unencrypted, uncompressed LAB data 240and LAB signatures 244. While the efficiency of random access overnetwork file data is maintained, modifications potentially due toimproper tampering with the contents of the network file are nonethelessdetectable on an individual logical access block 224 level. Theconventional necessity of reading the entire network file to compute asecure digest to detect tampering is not required.

[0090] In an alternate embodiment of the present invention, an errorcorrection trailer 246 is provided to store an ECC value computed overthe LAB data field 240, any LAB compression header 242 and the LABsignature 244. ECC values are computed on creation of the logical accessblocks 244. Upon retrieval of logical access blocks 244, the ECC valueis used to correct bit errors that may occur as a consequence ofextended network infrastructure transport of the logical access blocks244. In particular, bit errors may be introduced by network routersoperating at the TCP layer and above. Such infrastructure induced biterrors are otherwise detected from the LAB signature 244, but are thenindistinguishable from data tampering. Use of the error correction field246 serves to independently protect the integrity of the logical accessblocks 244.

[0091] The file management header 226 and the headers 244 and trailers242, 246 of the logical access blocks 244 may be included in-band, orin-file, as generally represented in FIG. 8D, as part of the file 220 asultimately stored by the network storage resources 16. Different in-bandlayouts can also be used to optimize access to the logical access blockdata 240. The file management header 226, digital signatures 242, andcompression headers 244 can be collected into one or more in-band superblocks. The size of these super blocks and the remaining logical accessblock data 240 can be sized to optimize I/O performance of the networkstorage resources 16.

[0092] Alternately, and potentially preferred, only the logical accessblock data 240 is stored by the network storage resources 16 in-band asthe network file 220. The file meta-data, including the managementheader 226 and the headers 244 and trailers 242, 246, corresponding to anetwork file 220 are stored in a separate, meta-data or shadow file. Anyparallel storage structure that maintains the relationship between theshadow file and the in-band network file 220 may be used. The shadowfiles can be created and stored on the network resources 16 within thesame storage space as the network files 220, within a different storagespace potentially physically remote from the network files 220, or onthe platform 50 provided the parallel association of the shadow fileswith the network files 220 is maintained. For example, shadow files canbe stored in the same directory with the counterpart network files 220and identified by file names that are a defined permutation of thenetwork file 220 file names. The shadow files can alternately be storedin a parallel directory structure diverging from a defined root orrelative root node of the network storage resources 16. In either case,the defined relationship between the shadow files and the correspondingnetwork files 220 is determined and known to the secure network fileaccess appliance 12, which can ensure the parallel reading and writingof the shadow files with corresponding reading and writing of thenetwork files 220.

[0093] Referring again to FIG. 7, the packet to LAB processing 194preferably utilizes, as required, the hardware accelerators 62 toperform encryption 196 and compression 198 over the segments of packetpayload data 222. The logical access blocks 224 _(1-N), togethercontaining the packet payload data 222 of a network file data packet,are then collected into a new network file data packet and passed to thenetwork interface 192 for transport to the networks storage resources16.

[0094] Network file data packets received through the network interface192 are similarly processed 200 to expose and deliver the networkcontrol information 114 for authentication and access processing 176,184 and logical access blocks 224 _(1-N) contained in the packet payloaddata to a logical access block to packet data process 202. The provisionfor authentication and access processing 176, 184 permits evendistributed, potentially client-based network storage devices to beequally secured and made accessible as other network storage resources16. In the preferred embodiments of the present invention, minimalauthentication and access processing 176, 184 is performed for networkfile data packets received from dedicated network storage resources 16.

[0095] The logical access blocks 224 _(1-N) received in the packetpayload data are processed 202 to apply error correction, where theerror correction field 246 is present, and validate the integrity of theLAB data fields 240, including the LAB compression headers 244 ifpresent, against the digital signature 242 values. The file managementheader 226 is read, typically in advance, by the NFS/CIFS state machineprocess 186 to obtain the encryption key identifier from the field 234and compression algorithm identity, if applicable from the options indexfield 236. The LAB data fields 240 are then decompressed 204, ifapplicable, and decrypted 206. The NFS/CIFS state machine process 186,based on the pending inbound file data read request transaction,identifies an offset and range-selected portion of the combined logicalaccess block 224 _(1-N) data representing client read requested data.The selected data is then incorporated into a network file data packetand provided to the network interface 172 for transport to thetransaction identified client 22, 24.

[0096] For the preferred embodiments of the present invention, anadministration interface 208 provides access to and configuration of thepolicy parser 180 and policy data store 182. A network communicationsinterface 210 provides access to the administration interface 208independent of the inbound and outbound network interfaces 172, 192.

[0097] The software architecture 170 is preferably extended, as shown inFIG. 9, to provide additional security appliance-oriented features. Theextended architecture 250 includes IP filter layers 252, 254implementing firewall-type filtering for network connections madethrough the network interfaces 172, 192. A filter rules store 256preferably maintains iptables-type specifications that define the IPaddresses, network protocols, and internet ports permitted to passnetwork packets through the IP filter layers 252, 254. Preferably, theIP filter layers 252, 254, and particularly the inbound IP filter layer252, is set to reject all connections except those pertaining to networkfile access operations, including the NFS, CIFS, RPC, and mountprotocols. These network file data packets passed by the IP filterlayers 252, 254 are directed for packet/LAB processing 258 as performedby the software architecture 170. Unauthorized connection attempts andaccess requests lacking adequate policy-based permissions are thereforepreferentially received, detected, and audited by the softwarearchitecture 170.

[0098] The flexible analysis capabilities of the authentication andaccess controls 176, 184 and policy parser 180, particularly based onaccess to the full set of control information 114, 122, allows a morerefined identification of potential abuse patterns and a wider varietyof remedial actions, including dynamically blocking specific source IPs,logging detailed information, and issuing real-time administrativealerts. The security and reporting strength of the firewall filters 252,254 is appropriate for handling connection attempts unrelated to theprimary functions of the secure network file access appliance 12. Thefirewall filters 252, 254 may also be utilized to proxy selected networkdata packets, including potentially network file data packets, throughthe secure network file access appliance 12, utilizing a bypass route260. In the case of VPN 42 and network file access appliance 12′designated source IP addresses and protocols can be identified andappropriately bypassed 260.

[0099] For the fixed scale, hardware platform 50, the firewall filters252, 254 are preferably implemented through the kernel execution of theoperating system iptables module by the main processors 54. On thescalable hardware platform 80, the firewall filter layers 252, 254 arepreferably implemented on the ingress and egress processors 86, 88, withthe bypass routed network packets being passed directly between theingress and egress processors 86, 88. The filter rules maintained in thefilter rules store 256 are administered through the administrationinterface 208.

[0100] An NFS/CIFS read transaction 270, structured in accordance with apreferred embodiment of the present invention, is shown graphically inFIG. 10A. A read target file, consisting of a file management header 226and a sequence of logical access blocks 224 _(1-N), exists on thenetwork storage resources 16. In general, an inbound read requestidentifies an offset and range of data to read 272. Outbound readrequests are issued to read 274, 276 the file management header 226 andan encompassing, block-aligned sequence of logical access blocks 224_(A-X). The read request 276 retrieves the requested logical accessblocks 224 _(A-X) in a series of one or more network file data packets,which are then processed to complete the inbound read request byreturning one or more network file data packets containing the readrequest data 272.

[0101] The specific processing 280 associated with an NFS/CIFS readtransaction 270 is shown in FIG. 10B. The secure network file accessappliance 12, on receiving a firewall-filtered file data read request,exposes 282 and parses 284 the network control information 114 againstthe policy rules and data 182, 184. A policy compliance failure isreported 286 by return issuance of an NFS/CIFS appropriate reply networkdata packet.

[0102] Where the read request complies with the defined policyrequirements, the file related access control information is optionallyread 288 from the network storage resources 16 to confirm existence ofthe file and evaluate applicable read data permissions. Where thepermissions check is performed and fails, nonexistence of the file orinadequate permissions are reported 286 without issuing the read filerequest to the network storage resources 16. The file meta-data,including the file management header 226 for the request target file, isalso read 288 from the network storage resource 16. A block-alignedlogical access block offset 290 and range 292 are determined and used tocreate and issue an outbound read request directed to the networkstorage resources 16. The read data offset is adjusted to account forthe size of the file management header 226 as stored at the beginning ofthe file. Where the logical access blocks 224 _(A-X) contain compresseddata, file data reads of the LAB compression headers 244 may be requiredto determine adjustments to both the read data offset and anencompassing read request range.

[0103] As the requested logical access blocks 224 _(A-X) are received294, error correction is applied 296, depending on whether the LAB ECCfield 246 is present, decrypted 298 utilizing the key associated withthe key name determined from the key identifier field 234 of the filemanagement header 226, and decompressed 300, depending on whether thefile management header 226 includes the compression option andidentifies a corresponding algorithm. The LAB digital signatures 242 areused to check the integrity of the retrieved file data. A failure of theintegrity check for any of the logical access blocks 224 _(A-X) mayresult in a re-reading of some or all of the logical access blocks 224_(A-X), to protect against soft-errors, with persistent errors beingultimately reported by the return issuance of an NFS/CIFS appropriateerror network data packet. Preferably, both soft and persistent errorsare logged by the secure network file access appliance 12. Persistenterrors, recognized through the operation of the NFS/CIFS state machineprocessing 186 of the inbound read request, are further preferablyasserted against the policy parser 180 for evaluation and subsequentlyissued 302 as a tampering alert message through the administrativeinterface 208. Finally, as file data is received and processed inresponse to the outbound read request, the file data identified in theinbound read request is assembled 304 into one or more reply networkfile dat packets and returned.

[0104] An NFS/CIFS create file transaction 310, as shown graphically inFIG. 11A, preferably operates to create a new file containing a new filemanagement header 226. As further detailed in FIG. 11B, a create filerequest process 320 initially exposes 322 and parses 324 the networkcontrol information 114, with any policy compliance failures resultingin the return issuance of an NFS/CIFS appropriate reply network datapacket. Provided the file create request complies with the definedpolicy requirements, directory information is optionally read 328 fromthe network storage resources 16 to obtain the target file creationpermissions. Where the permissions check is performed and fails,non-existence of the target directory and inadequate permissions arereported 326 without asserting a create file request to the networkstorage resources 16.

[0105] A file management header 226 is then created 330. Throughoperation of the NFS/CIFS state machine processing 186, the policyparser 180, based on the stored values provided from the policy datastore 182, generates and provides the necessary values for the securityparameter index 230. In particular, the policy parser 180 preferablyassociates encryption keys and compression choices against directoryspecifications, including mount points. Thus, the target location of thefile to be created is utilized to determine whether encryption andcompression are to be applied and the applicable key and algorithms forimplementation. A secure identifier based on the key name andcompression and compression algorithm identifiers are computed andstored in the new file management header 226 along with computed CRC andsignature values.

[0106] The NFS/CIFS state machine 186 next provides for the creation andissuance 332 of an NFS/CIFS create file request to the network storageresources 16 utilizing the directory specification provided by theinbound create file request. For in-band storage of the file managementheader 226, an NFS/CIFS file write request, containing the filemanagement header 226, is then created and issued 334 to the networkstorage resources 16. Where a shadow meta-data file is designated foruse, an NFS/CIFS file create and write requests, the latter containingthe file management header 226, are created and issued 334 to thenetwork storage resources 16 to create the shadow file. Finally, anNFS/CIFS appropriate create file reply network data packet is returnedto the client.

[0107] An NFS/CIFS write transaction 340, structured in accordance witha preferred embodiment of the present invention, is shown graphically inFIG. 12A. The write of file data to an existing file in the networkstorage resources 16 uses a read, modify, write procedure. An inboundwrite data request specifies an offset and range of write data 342 thatis provided in a transaction sequence of one or more network file datapackets. In most instances, the write request data will be unaligned tothe logical access blocks 224 _(1-N) existing in the stored file. Thefile management header 226 and any partially overlapped logical accessblocks 224 _(A), 224 _(X) are preemptively read 344, 346, 348,permitting the overlapped logical access blocks 224 _(A), 224 _(X) to bedecrypted and decompressed as required. An overlay of the inbound writedata 342 with the block-aligned read data is then performed. Theresulting block-aligned write data is then processed into logical accessblocks 224 _(A-X) and written 350 in a write transaction sequence of oneor more network file data packets to the network storage resources 16.

[0108] The preferred process 360 of performing an NFS/CIFS write requesttransaction is shown in FIG. 12B. The received write file data requestis received and processed 362 to expose the network control information114. This information is then parsed 364 against the establishedpolicies 180, 182, with any compliance failures being reported 386. Thenetwork control information 114 is then further processed 368 toidentify the target file stored by the network storage resources 16,create and issue read requests to obtain the file meta-data, includingthe file management header 226. The logical access block offset andrange are then determined 370, 372, adjusting as needed for the presenceof the file management header 226 and compression of the logical accessblock 224 contained data. A file lock is asserted against the rangelogical access blocks 224 _(A-X). The initial and terminal logicalaccess blocks 224 _(A), 224 _(X) are read 374 from the network storageresources 16, corrected 376 if the LAB ECC field 246 is present,decrypted 378, and decompressed 380, as needed. Integrity failure errorsare reported 382. Data from the terminal logical access blocks 224 _(A),224 _(X) are merged 384 with the write data 342 and the combined data isresegmented 386, compressed 388 as appropriate, and encrypted 390. Asapplicable, LAB ECC values are computed and added 392 to the assembled394 series of logical access blocks 224 _(A-X). As the logical accessblocks 224 _(A-X) are assembled, one or more write network file datapackets are constructed and sent to the network storage resources 16.Once the writing the logical access blocks 224 _(A-X) has completed, thefile lock is released.

[0109] Thus, a system and methods for establishing secure network fileaccess between users of distributed computer systems and network-basedstorage systems has been described. In view of the above description ofthe preferred embodiments of the present invention, many modificationsand variations of the disclosed embodiments will be readily appreciatedby those of skill in the art. It is therefore to be understood that,within the scope of the appended claims, the invention may be practicedotherwise than as specifically described above.

1. A network storage architecture supporting securely controlled accessand transfer of data between a client computer system and a network datastore, said network storage architecture comprising: a) an agentprogram, executed on a client computer system, operative with respect toan application program, executable by said client computer system toaccess a network data store, to develop authentication data with respectto said application program; and b) a network appliance, coupleablethrough a communications network to said client computer system,interoperable with said agent program to receive and validate saidauthentication data, said network appliance providing a response messageto said agent program to control execution of said application program.2. The network storage architecture of claim 1 wherein saidauthentication data includes user and session data.
 3. The networkstorage architecture of claim 2 wherein said authentication dataincludes a secure signature of said application program.
 4. The networkstorage architecture of claim 1 wherein said agent program is operativeto obtain user authentication and collect data with respect to usersessions and processes to develop said authentication data.
 5. Thenetwork storage architecture of claim 4 wherein said agent program isfurther operative to generate a secure signature of said applicationprogram and provide said secure signature as part of said authenticationdata.
 6. The network storage architecture of claim 1 wherein saidnetwork appliance includes a policy parser operative to evaluate saidauthentication data and a policy data store including predeterminedpolicy data accessible by said policy parser.
 7. The network storagearchitecture of claim 6 wherein said predetermined policy data, asevaluated by said policy parser, is determinative of said responsemessage.
 8. A network storage architecture supporting securelycontrolled access and transfer of data between a client computer systemand a network data store, said network storage architecture comprising:a) an agent program, executed on a client computer system, responsive toa source file request issued with respect to a network data store by anapplication program executed by said client computer system, said agentprogram being operative to develop authentication data with respect tosaid application program and to provide a file request message includinga representation of said source file request and said authenticationdata; and b) a network appliance, coupleable through a communicationsnetwork to said client computer system and responsive to said filerequest message, said network appliance including a policy parseroperative to evaluate said file request message and a policy data storeincluding predetermined policy data accessible by said policy parser,said network appliance, responsive to the evaluation of said filerequest message, enabling performance of said source file request withrespect to said network data store.
 9. The network storage architectureof claim 8 wherein said authentication data includes an authenticatedidentification of a user associated with said application program. 10.The network storage architecture of claim 9 wherein said authenticationdata includes user session and context data.
 11. The network storagearchitecture of claim 10 wherein said authentication data includes asecure signature of said application program.
 12. The network storagearchitecture of claim 8 wherein said network appliance enables thegeneration of a modified file request corresponding to said source filerequest and directed to said network data store.
 13. The network storagearchitecture of claim 12 further comprising a first communicationsnetwork through which said file request message is received by saidnetwork appliance and a second communications network through which saidmodified file request is provided to said network data store.
 14. Thenetwork storage architecture of claim 13 wherein said network applianceincludes an encryption unit and wherein said network appliance furtherprovides for the cipher processing of file data transferred inconnection with said modified file request.
 15. The network storagearchitecture of claim 14 wherein said policy data store further providesfor the storage of an encryption key identifier determinable by saidpolicy parser on evaluation of said file request message and whereinsaid network appliance obtains an encryption key identified by saidencryption key identifier for use in the cipher processing of file datatransferred in connection with said modified file request.
 16. Thenetwork storage architecture of claim 15 wherein said authenticationdata includes a process identifier, corresponding to said applicationprogram as executed on said client computer system, a verified useridentifier, and a group identifier, and wherein said policy parser isoperative to qualify said file request message against saidpredetermined policy data with respect to said process identifier,verified user identifier, and group identifier.
 17. A method of securingaccess by a client computer system to file data stored on a storagedevice accessible by said client computer system, said method comprisingthe steps of: a) intercepting, by a first program as executed on aclient computer system, a data transfer request issued by a secondprogram, as executed on said client computer system, directed to a datafile stored by a client accessible file data store; b) first processing,by said first program, said data transfer request to associateauthentication data with said data transfer request; c) evaluating, by asecurity appliance coupled to said client computer system through acommunications network, said data transfer request, said authenticationdata, and access control data corresponding to said data file to qualifysaid data transfer request; and d) second processing to selectivelyenable said data transfer request to proceed relative to said data filedependent on the qualification of said data transfer request.
 18. Themethod of claim 17 wherein said authentication data includes process andcontext identification information.
 19. The method of claim 17 whereinsaid authentication data includes a verified user identifier and aprocess identifier.
 20. The method of claim 17 wherein saidauthentication data includes a verified user identifier, a processidentifier, a group identifier.
 21. The method of claim 17 wherein saiddata transfer request specifies a data range of file data and whereinsaid second processing step includes the step of modifying said datarange to accommodate block encryption of file data within said datafile.
 22. The method of claim 17 wherein said step of evaluatingassociates encryption control data with said data transfer request andwherein said second processing step, responsive to said encryptioncontrol data, includes cipher processing of file data transferred inconnection with said data transfer request.
 23. The method of claim 22further comprising the steps of: a) first transferring said datatransfer request to said security appliance through a firstcommunications network; and b) second transferring said data transferrequest relative to said client accessible file data store through asecond communications network.
 24. The method of claim 23 wherein,through said first and second transferring steps, said securityappliance is established a network portal through which network fileaccesses are routed between said client computer system and said clientaccessible file data store.
 25. A method of securing file accessoperations by a client computer system made with respect to a clientaccessible file data store, said method comprising the steps of: a)intercepting, by a first program executing on a client computer system,file operation requests issued by a second program, as executing on saidclient computer system, wherein said file operation requests are issuedwith respect to files stored in a filesystem accessible by said clientcomputer system; b) determining, by said first program relative to apredetermined file operation request, authentication data for saidsecond program, wherein said authentication data includes user andprocess identification data and a representation of said predeterminedfile operation request; and c) enabling, by a security applianceresponsive to said authentication data, said predetermined fileoperation request with respect to a file identified by saidpredetermined file operation request, wherein said enabling step isdependent on qualification, by said security appliance, of saidauthentication data against policy data defining operation permissionsrelative to said file.
 26. The method of claim 25 further comprising thesteps of: a) associating an encryption key with said predetermined fileoperation request determined from the qualification of saidauthentication data against said policy data; and b) cipher processing,using said encryption key, file data transferred relative to said file.27. The method of claim 26 wherein said step of cipher processingincludes modifying the specification of said predetermined fileoperation request to accommodate encryption of file data transferredrelative to said file.
 28. The method of claim 27 wherein said step ofcipher processing is performed on said security appliance.
 29. Themethod of claim 28 wherein said authentication data includes a verifieduser identification and a login process identification.
 30. A securityappliance for securing access by client computer systems to persistentlystored data files, said security appliance comprising: a) a processorcoupleable to a client computer system to receive an access requestmessage, wherein said access request message includes authenticationdata and an identification of a file operation directed to an identifieddata file stored in a persistent data file store; and b) a policy datastore, accessible by said processor, providing for the storage ofpredetermined file operation qualifiers applicable to data files presentin said persistent data file store, wherein said policy data store ismaintained secure by said processor with respect to said client computersystem, and wherein said processor is operative to selectively enablesaid file operation dependent on an evaluation of said predeterminedfile operation qualifiers with respect to said access request message.31. The security appliance of claim 30 wherein said authentication dataincludes a verified user identifier and a group identifier and whereinsaid processor is operative to discriminate said verified useridentifiers, said group identifier, said file operation and saididentified data file against said predetermined file operationqualifiers to obtain said evaluation.
 32. The security appliance ofclaim 31 wherein said policy data store further provides for the storageof encryption keys in association with said predetermined file operationqualifiers and wherein said processor is operative to retrieve apredetermined encryption key from said policy data store dependent onsaid evaluation.
 33. The security appliance of claim 32 wherein saidprocessor, responsive to said evaluation, is further operative toprovide for said file operation to be passed to said persistent datafile store.
 34. The security appliance of claim 33 wherein saidprocessor, responsive to said evaluation, is further operative to modifya specification of said file operation to accommodate the transfer ofencrypted data in connection with the performance of said file operationwith respect to said identified data file.
 35. The security appliance ofclaim 34 wherein said processor includes an encryption engine operativeto process encrypted data transferred with respect to said identifieddata file.